Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:
Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
При включении ВМ вы получаете ошибку " File not found"
Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено
Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.
В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:
Часть 1 - восстановление основного VMDK виртуальной машины
Перед выполнением операций ниже обязательно сохраните полную копию папки виртуальной машины, и только после этого проводите все описанные ниже операции. Если у вас есть резервная копия виртуальной машины, и ее восстановление вас устраивает - то лучше сделать эту операцию вместо описанной ниже процедуры исправления дисков, так как вероятность ошибиться в ней велика.
Если вкратце, то для восстановления вам нужно выполнить следующие шаги:
1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.
2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk
Делается это командой:
# ls -l <имя диска>-flat.vmdk
На выходе мы получим размер диска в байтах. Вывод будет выглядеть примерно так:
-rw------- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk
3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:
# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk
После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).
Если у изначальной машины диск был не растущим по мере наполнения (thin disk), то последнюю строчку, выделенную красным, можно не добавлять.
Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.
Консистентность виртуальной машины можно проверить командой:
vmkfstools -e filename.vmdk
Если все в порядке, то в ответе команды вы получите вот такую строчку:
Disk chain is consistent.
Если же исправить ситуацию не получилось, то будет вот такой текст:
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).
После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.
Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)
Ситуация усложняется, когда у исходной виртуальной машины были снапшоты, тогда папка с ней выглядит следующим образом (красным выделены важные для нас в дальнейших шагах файлы):
drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf
Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):
1. Определяем нужные нам файлы
Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).
Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.
2. Создаем новый дескриптор снапшота
Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:
# cp examplevm.vmdk examplevm-000001.vmdk
3. Меняем указатели на файл с данными для снапшота
Теперь нужно открыть созданный файл в текстовом редакторе и начать его исправлять. Пусть он выглядит вот так:
# Disk DescriptorFile
version=1
encoding="UTF-8" CID=19741890
parentCID=ffffffff
createType="vmfs"
Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.
С данным файлом нужно сделать следующие манипуляции:
Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
Строчку createType="vmfs" заменяем на createType="vmfsSparse"
Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)
4. Добавляем данные специфичные для снапшота
Теперь нам надо добавить в указатель снапшота кое-что новое:
Под строчкой createType="vmfsSparse" добавляем строчку
parentFileNameHint="examplevm.vmdk"
Ну и теперь надо убрать лишнее. Удаляем из файла следующие строчки, которые нужны только для основного родительского диска:
После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:
vmkfstools -e filename.vmdk
Ну и помните, что все эти действия по цепочке вы можете провернуть для следующих уровней дочерних снапшотов, если их диски с данными в порядке. Главное - не забывайте делать резервные копии перед любыми операциями!
На днях обновилась известная многим администраторам виртуальной инфраструктуры утилита RVTools до версии 4.4.1. Напомним, что она предназначена для помощи пользователю VMware vSphere в различных аспектах при выполнении рутинных операций в виртуальной среде серверов ESXi и виртуальных машин. В прошлый раз об RVTools 4.3.1 мы писали вот тут.
Давайте посмотрим, что нового появилось в RVTools 4.4.1:
Теперь утилита разрабатывается на Visual Studio 2022.
RVTools использует обновленный VMware vSphere Management SDK 8.0.
Log4net обновлен до версии 2.0.15.
Компонент RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля.
Новые колонки на странице vInfo: емкость диска в MiB, Folder ID, роль Fault tolerance, операции Reboot/Poweroff, опция EFI Secure boot, SMBIOS UUID.
Новая колонка на странице vCPU - Numa Hotadd Exposed. Это булевое значение, показывающее работает ли NUMA-топология при включенном CPU hotadd.
Новые колонки на странице vDisk: Disk UUID и Disk sharing mode.
На всех страницах, относящихся к ВМ, колонка с тэгами поставлена перед колонкой Datacenter. Также изменен текст тултипа VM UUID на "VirtualCenter-specific 128-bit UUID of a virtual machine".
Новые колонки на странице vSource: version, patch level и VI SDK Server.
На странице vHealth путь /storage/archive исключен из проверки free disk capacity, так как этот раздел может быть заполнен изначально в нормальной конфигурации (подробнее тут).
Исправлена ошибка с некорректным отображением колонки Primary IP Address на странице vInfo.
Решена проблема на странице vNetwork, когда нельзя было понять, является ли IP-адрес типом ipv4 или ipv6.
Скачать новую версию RVTools 4.4.1 можно по этой ссылке. Описание отображаемых параметров находится тут.
Как написали коллеги с сайта virten.net, при установке платформы VMware ESXi 7 или 8 на сервер с процессорами Intel Core 12 поколения возникает розовый экран смерти (PSOD), содержащий следующие сообщения:
HW feature incompatibility detected; cannot start
Fatal CPU mismatch on feature "Hyperthreads per core" Fatal CPU mismatch on feature "Cores per package" Fatal CPU mismatch on feature "Cores per die"
Проблема здесь заключается в том, что новая архитектура процессоров Intel идет с ядрами двух типов - Performance-cores и Efficient-cores. Начиная с vSphere 7.0 Update 2, в ядро гипервизора был добавлен параметр cpuUniformityHardCheckPanic для того, чтобы избежать подобной проблемы, которая проявляется в следующих версиях платформы виртуализации:
vSphere / ESXi 8.0 или более поздние
vSphere / ESXi 7.0 Update 2 или более поздние
1. Итак, в самом начале установки ESXi нажимаете SHIFT+O, чтобы изменить параметры загрузки. Далее в появившейся строке вводите:
cpuUniformityHardCheckPanic=FALSE
2. После этого нажимаете Enter и дожидаетесь окончания установки.
3. Затем во время первой загрузки опять нажимаете SHIFT+O и вводите ту же самую строчку.
4. А уже когда гипервизор загрузится, нужно добавить следующую строчку в параметры ядра, чтобы отключить проверку, а ESXi не вылетал в розовый экран при каждой загрузке:
# esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE
Также есть метод, описанный для установки через механизм автоматизированного развертывания Kickstart:
1. Создаем флэшку USB с ISO-образом ESXi, как написано здесь.
2. Открываем файл /efi/boot/boot.cfg в редакторе и добавляем следующую опцию в строчку kernelopt= параметров ядра:
ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE
3. Далее вам надо создать файл /KS.CFG для конфигурации Kickstart и в секциях %post (пост-параметры установки, но до первой загрузки) и %firstboot (первая загрузка) добавить следующее:
# NTP
esxcli system ntp set -s pool.ntp.org
esxcli system ntp set -e 1
4. Далее можете провести установку с USB-флэшки, а через пару минут вы уже сможете получить доступ к ESXi через консоль или по SSH.
5. Если вы используете механизм Secure Boot, то обычно секция %firstboot не применяется (так работает по умолчанию на большинстве систем). Поэтому вам потребоваться ввести команды этой секции вручную или отключить Secure Boot. С командами раздела %post все будет в порядке.
6. По окончании установки через Kickstart все будет работать:
На прошедшей осенью этого года главной конференции о виртуализации Explore 2022 компания VMware сделала немало интересных анонсов, главным из которых стал выпуск новых версий платформ vSphere 8 и vSAN 8. На американской и европейской конференциях много говорили о будущих новых продуктах и технологиях VMware, но несколько незамеченным остался переход VMware на новую схему релизов платформы vSphere...
За релизами платформы VMware vSphere 8, у которой недавно состоялся выпуск General Availability, многие забыли о том, что большинство пользователей в производственной среде используют еще VMware vSphere 7. Недавно компания VMware выпустила обновления компонентов этой версии платформы - ESXi 7.0 Update 3i (на 13 декабря почему-то недоступен для скачивания) и vCenter 7.0 Update 3i. Напомним, что об обновлении VMware vSphere 7 Update 3f мы писали вот тут (а здесь - о возможностях Update 3), с тех пор вышел еще апдейт 3g, а сегодня мы расскажем об очередном пакете - 3i.
Давайте посмотрим, что нового в ESXi 7.0 Update 3i:
Поддержка функций vSphere Quick Boot для сервера HPE ProLiant MicroServer Gen10 Plus v2
Исправления для уязвимостей CVE-2022-31696 и CVE-2022-31699, описанных в статье VMSA-2022-0030
В VMware vCenter 7.0 Update 3i появились следующие улучшения:
Исправления для уязвимостей CVE-2022-31697 и CVE-2022-31698, описанных в статье VMSA-2022-0030
Исправление для уязвимости CVE-2021-22048, описанное в статье VMSA-2021-0025
Обновление решения VMware vSphere with Tanzu (подробнее - в Release Notes)
Обновление Photon OS (подробнее тут, в основном патчи безопасности)
Как мы видим, обновления чисто косметические, но исправлены некоторые актуальные проблемы безопасности, поэтому обновиться стоит. Очевидно, что новый функционал в vSphere 7 добавляться уже не будет, так как идет работа над обновлением vSphere 8.
Скачать VMware ESXi 7.0 Update 3i и VMware vCenter 7.0 Update 3i можно по этой ссылке.
На сайте проекта VMware Labs появился новый интересный продукт - Cluster Rules Manager (CRM). С помощью данной утилиты можно провести обследование виртуальной инфраструктуры на предмет правил DRS affinity и anti-affinity rules. Первые определяют обязательное сосуществование ВМ на одном хосте ESXi (например, критичный сервис с высокой интенсивностью сетевого и дискового взаимодействия), а вторые - наоборот, невозможность существования ВМ на одном хосте (например, для целей отказоустойчивости и независимости от единой точки отказа оборудования).
По итогам использования этого средства через веб-консоль администраторы могут провести аудит текущих правил DRS, а также делать их импорт и экспорт в рамках инфраструктуры VMware vSphere.
Давайте посмотрим на возможности VMware Cluster Rules Manager:
Аудит правил anti-affinity для всех виртуальных машин в рамках сервера vCenter.
Импорт правил DRS affinity rules из разных серверов vCenter.
Экспорт правил DRS affinity rules в новый vCenter с сервера vCenter, гле они уже настроены.
Отчет о правилах, содержащий различные умные метрики - пользователь может выбрать, на каком уровне он будет сгенерирован (vCenter, датацентр или кластер). Отчет можно экспортировать в HTML-формат.
Отчет в реальном времени по ассоциациям VM-Rule. Можно выбрать виртуальную машину, и отчет будет содержать информацию обо всех правилах DRS, которые затрагивают данную ВМ. Этот отчет также можно генерировать на разных уровнях - ВМ, хост ESXi, кластер, датацентр и сервер vCenter. Его также можно экспортировать.
Возможность соединяться с разными vCenter в интерфейсе продукта.
Скачать VMware Cluster Rules Manager (CRM) можно по этой ссылке. Такую утилиту мы давно ждали, правда пока интерфейс оставляет желать лучшего. Ждем следующих версий!
На сайте проекта VMware Labs вышло еще одно полезное обновление - комплект драйверов USB Network Native Driver for ESXi версии 1.11. USB-драйвер для ESXi может понадобиться для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этого комплекта драйверов мы рассказывали тут.
Основным и единственным нововведением данного комплекта стала поддержка гипервизора VMware ESXi 8.0 в составе VMware vSphere 8.0 (пакет SXi800-VMKUSB-NIC-FLING-61054763-component-20826251.zip).
Актуальная таблица поддерживаемых сетевых адаптеров на сегодня выглядит так:
Установка драйвера для vSphere версии 7.0 и выше выполняется командой:
По итогам конференции Explore 2022 компания VMware представила линейку продуктов Aria, пришедшую на смену семейству vRealize. В нее вошло онпремизное решение Aria Operations 8.10, а также облачное Aria Operations Cloud. Оба они предназначены для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах.
Одной из главных возможностей Aria Operations являются дэшборды, которые показывают различные метрики виртуальной инфраструктуры, собираемые как напрямую, так и с помощью менеджмент-паков. Сегодня мы посмотрим на интересный дэшборд CPU Core, который предоставляет информацию об используемых ядрах CPU на уровне разных объектов - от датацентров до хостов VMware ESXi.
В рамках анонсированной недавно подписки vSphere+ и решения vRealize Cloud Subscription Manager появилась возможность лицензировать компоненты виртуальной инфраструктуры vSphere и Aria на базе ядер процессоров (CPU Cores). Ниже мы посмотрим, как можно с помощью Aria Operations визуализовать распределение процессоров, чтобы оптимизировать потребление лицензий. Об этом рассказал Karthic Kumar в блоге VMware.
Дэшборд - это мощный функционал Aria Operations, который дает администратору коллекцию виджетов и связанную информацию об объектах датацентра. Мы создадим суперметрики (super metrics) и представления (Views), которые предоставляют данные для дэшборда Core distribution. Чтобы упростить процесс, используем шаблон, в котором есть следующие файлы:
Super Metrics (supermetrics.json)
Views (views.zip)
Dashboard(dashboard.zip)
Итак, скачиваем файл шаблона и заходим в консоль Aria / vRealize Operations под аккаунтом администратора. Нам надо импортировать суперметрики из JSON-файла, для этого идем в Configure –> Super Metrics –> Import и выбираем Supermetric.json:
После импорта у нас в списке появится суперметрика CorePerSocket. Выбираем для нее пункт Edit и включаем ее в политике по умолчанию, чтобы она применилась:
Далее нужно импортировать представления (Views), которые забирают данные суперметрик. Идем в Visualize –> Views –> Manage–> Import и выбираем файл views.zip:
После этого мы увидим импортированные представления в списке:
Теперь пришло время импортировать сам дэшборд. Идем в Visualize –> Dashboards –> Manage–> Import и выбираем файл Dashboard.zip:
Теперь можно кликнуть на Core Distribution в списке дэшбордов. Чтобы данные актуализировались может пройти до 15 минут (если вы видите надпись "No data available"):
В отображаемых данных вы увидите распределение ядре по датацентрам и хостам. Эти виджеты позволят вам получить информацию о соответствии использования лицензий по разным объектам вашей гибридной инфраструктуры. Ну а вы всегда сможете кастомизировать этот дэшборд, чтобы он соответствовал вашим требованиям.
Все из вас, я думаю, знают о продукте Veeam Backup and Replication, ставшем уже стандартом де-факто для резервного копирования виртуальной инфраструктуры VMware vSphere и обеспечения доступности виртуальных датацентров.
Вы также, конечно же, в курсе, что недавно компания VMware объявила о финальной доступности (General Availability) своей обновленной платформы виртуализации VMware vSphere 8. Очевидно, сразу же встал вопрос резервного копирования виртуальных машин на этой платформе.
Компания Veeam недавно выпустила статью KB 2443 о поддержке резервного копирования ВМ на VMware vSphere 8 продуктом Veeam Backup and Replication 11a (билд 11.0.1.1261 P20220302). Суть ее в том, что в целом сейчас обеспечивается работоспособность процесса бэкапа для серверов VMware ESXi 8.0 (это протестировали инженеры Veeam), но с некоторыми ограничениями:
Как вы знаете, недавно компания VMware сделала публично доступной для всех обновленную версию платформу виртуализации VMware vSphere 8 в рамках релиза General Availability (ранее состоялся выпуск продукта на этапе Initial Availability).
Администраторы, которые давно следят за выпусками платформы vSphere, знают, что при первоначальном выпуске гипервизора в официальном списке совместимости HCL (Hardware Compatibility List) не все серверные системы приводятся как сертифицированные для последнего релиза vSphere. Например, некоторые могут заметить, что многие серверы различных производителей, которые поддерживались в vSphere 7 Update 3, пока отсутствуют в HCL.
На это обратил внимание Florian Grehl, автор сайта virten.net. Причина такого факта проста - при первоначальном выпуске новой версии ESXi не все серверные системы успевают должным образом протестировать и сертифицировать.
Именно такой список и приводит Флориан, он довольно большой, поэтому лучше всего посмотреть его тут. Список официально несертифицированного оборудования становится все короче, поэтому на virten.net публикуются его обновления (последнее доступное - от 14 ноября). В списке пока представлены только серверы от Cisco, DELL, Fujitsu, Hewlett Packard Enterprise, Hitachi, IBM, Lenovo, Inspur, Huawei и Supermicro.
При клике на выбранный сервер откроется его карточка в VMware HCL:
Надо понимать, что тот факт, что система не сертифицирована, не означает, что VMware vSphere / ESXi на ней работать не будет. Просто вендоры самостоятельно занимаются сертификацией, а значит делают это каждый в своем темпе. Поэтому, если ваш сервер есть в списке, то лучше всего спросить о его сертификации у вендора напрямую.
На сайте проекта VMware Labs вышло обновление платформы VMware ESXi Arm Edition 1.11. Напомним, что этот продукт представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey. О прошлой версии ESXi для ARM 1.10 мы писали в июле этого года.
Давайте посмотрим, что нового появилось в ESXi Arm Edition 1.11:
Поддержка CPU accelerated crypto (например, NEON и Armv8 Cryptographic Extensions) для встроенных служб ESXi
Исправлена проблема с xterm-256color terminfo. Программа Terminal в macOS (или любой другой современный терминал) теперь корректно отображает данные команды esxtop
Поддержка виртуального модуля vTPM с функциями Secure Boot и шифрования ВМ
Поддержка аппаратного обеспечения GICv4
Добавлены VMware Tools для Windows
Решена проблема с драйвером ixgben
Обратите внимание, что начиная с версии 1.10, поддерживается апгрейд с ESXi Arm Edition 1.x. Чтобы сделать апгрейд вам понадобится создать загрузочное USB-устройство из ISO-образа и инициировать апгрейд в интерактивном режиме через ESXi Console. Использование VUM/vSphere Lifecycle Manager пока не поддерживается.
Известные на данный момент проблемы:
Системы Ampere Altra могут вывалиться в розовый экран (PSOD) при использовании AHCI-дисков
Графический инсталлятор Ubuntu 22.04 LTS не работает, используйте Ubuntu 22.10
Загрузить VMware ESXi ARM Edition 1.11 можно по этой ссылке.
Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.
Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.
Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.
Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).
Итак для этого вам понадобятся:
Действующий vCenter Server не ниже седьмой версии
Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.
Пример исполнения сценария показан ниже:
В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:
Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:
Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.
Вчера мы писали о том, что решение VMware vSphere 8 стало доступным для загрузки (Initial Availability). Анонсированная на конференции Explore 2022 платформа приобрела не только новые функции клиента vSphere Client, предназначенного для управления инфраструктурой на базе vCenter, но и получила новую версию хостового клиента для отдельных серверов ESXi Host Client 2, который удобно использовать, когда vCenter недоступен.
Напомним, что в прошлый раз о этом клиенте мы писали вот тут, тогда VMware планировала выпустить его второе поколение в конце 2021 года. Теперь Host Client 2 поддерживает не только управление инфраструктурой vSphere 8, но и серверы виртуализации vSphere 7.0 Update 6 (обновление пока не вышло).
Итак, что же нового в VMware ESXi Host Client 2:
1. Обновленная иконка приложения
Самое главное:)
2. Новый дизайн интерфейса на базе фреймворка Clarity
Многие из вас в курсе, что VMware перевела почти все свои интерфейсы на собственный open source фреймворк Clarity, и хостовый клиент стал очередным продуктом, который также был на него переведен. Рабочие процессы теперь выглядят более опрятно, а шаги мастеров - более организованно:
Браузер датасторов теперь дает больше информативности, а сами надписи и информационные лейблы стали более читаемыми. Файлы теперь можно загружать в параллельном режиме в фоне, а колонки позволяют обеспечивать видимость глубокой структуры каталогов:
3. Улучшенные иконки
Теперь в качестве визуальных элементов используется более 100 иконок, которые соответствуют таковым из конвенционального vSphere Client. Все иконки стали монохромными, чтобы не нагружать интерфейс и глаза.
Вот так выглядят портлеты свойств:
А вот так - действий:
4. Специальные возможности
Теперь для слабовидящих людей есть приятные улучшения. Элементы попадают в обводку:
Для полей ввода есть выделение (можно переключаться между ними по Tab или Shift+Tab), а на вкладках четко видны активные элементы:
5. Выбор светлой или темной темы
Тему можно выбрать в разделе Help > About > UI Preferences Theme:
На выбор есть 3 темы. Стандартная - это светлые цвета и мягкий контраст:
Классическая - для привыкших к стандартному белому фону:
И темная - для чувствительных к свету и любителей работать по ночам:
Но вообще по кнопке Customize можно настроить различные цвета для визуальных групп:
6. Кастомизабельный стартовый экран
В файле /etc/vmware/welcome можно редактировать иконку и приветственное сообщение, которые могут быть индивидуальными для каждой компании:
Таблица поддерживаемых браузеров сейчас выглядит так:
Клиент ESXi Host Client 2 в обновленной платформе VMware vSphere 8 доступен администраторам по ссылке в браузере:
Недавно мы писали о новой схеме релизов платформы VMware vSphere. Согласно ей, вводится два типа выпусков - IA (Initial Availability) и GA (General Availability), которые позволяет выровнять схему релизов с продуктами облачной линейки Cloud Services в рамках доступной пользователям подписки vSphere+.
Вчера VMware объявила о доступности vSphere 8 Initial Availability - продукт можно скачать по этой ссылке. О возможностях новой версии платформы мы писали вот тут.
IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать условия его применения от клиентов (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени будут публиковаться все найденные важные проблемы.
Ставить этот релиз в производственной среде вы можете, но это не рекомендуется. Пока его лучше обкатывать на тестовых серверах и смотреть, как все работает (особенно новый функционал платформы). После выхода vSphere 8 General Availability можно смело устанавливать продукт на свои производственные серверы, так как все критичные проблемы первоначального релиза будут уже решены.
Вчера мы писали о важном нововведении технологии горячей миграции виртуальных машин vMotion Notifications, появившемся в обновленной версии VMware vSphere 8, представленной на конференции Explore 2022. Она позволяет оповещать приложение гостевой ОС о скором начале миграции, чтобы оно могло подготовиться к ней и выполнить процедуры по приостановке сервисов или переключению на резервную систему для кластеризованных приложений.
Второе важное нововведение vMotion в ESXi 8 - это технология Unified Data Transport.
Для миграции включенных виртуальных машин используется протокол vMotion, который оптимизируют уже много лет - он многопоточный и асинхронный, что позволяет минимизировать время перемещения виртуальной машины между хостами ESXi. Этот же протокол использует и технология миграции хранилищ Storage vMotion. В то же время, если вам нужно переместить выключенную виртуальную машину (холодная миграция), то это может занять значительное время, так как в этом случае используется протокол Network File Copy (NFC).
Приведем ниже сравнительные характеристики обоих протоколов (реальная скорость миграции будет зависеть от параметров вашего окружения):
Network File Copy (NFC)
vSphere vMotion
Процесс в один поток
Глубоко оптимизированный многопоточный процесс
Синхронный ввод-вывод
Асинхронный ввод-вывод
Пиковая производительность 1.3 Gbps
Пиковая производительность 80 Gbps
Чтобы привести все к единому уровню производительности, VMware представила технологию Unified Data Transport (UDT) в платформе vSphere 8, которая комбинирует лучшие моменты обеих технологий NFC и vMotion.
Unified Data Transport (UDT) использует NFC как протокол для управления миграцией, а вот сама передача данных идет через протокол vSphere vMotion. Для того, чтобы эта технология работала, вам нужно активировать сервис "Provisioning" для интерфейса VMkernel (это может быть как новый, так и уже существующий интерфейс):
Если вы используете выделенный стек TCP/IP для vMotion, вы не сможете активировать службу "Provisioning" на этом же интерфейсе, в этом случае можно просто создать еще один интерфейс.
Посмотреть вживую, насколько хорошо работает технология Unified Data Transport для холодной миграции виртуальных машин, вы можете в видео ниже:
По итогам прошедшей конференции Explore 2022 компания VMware анонсировала платформу виртуализации vSphere 8. В прошлой версии платформы в технологии горячей миграции vMotion появилось очень много всего нового (например, вот, тут, тут, тут и тут). В этой версии также были сделаны некоторые улучшения vMotion, давайте на них посмотрим.
vSphere vMotion Notifications
Как вы знаете, переключение с одного процесса ВМ на другой целевого хоста ESXi занимает очень мало времени, и для большинства приложений это незаметно. Однако есть очень небольшое количество приложений, которые не могут пережить малые задержки (latency), поскольку очень интенсивно используют ресурсы CPU и хранилищ. Таких случаев буквально единицы, но VMware решила позаботиться и о них.
Теперь приложения могут быть написаны таким образом, чтобы они могли получить оповещение о предстоящей миграции vMotion и подготовиться к ней. Такие действия могут включать в себя остановку сервисов, заморозку приложения (quiescing), переключение на резервный инстанс в случае кластеризованного приложения, а также выполнение других операций.
Приложение может отложить миграцию vMotion на заданный таймаут, но не может отклонить и остановить ее. Вот как это работает (кликните на картинку для открытия анимации):
Приложение, через механизм VMware Tools, может быть оповещено о начале задачи vMotion. На полученную нотификацию оно реагирует согласно своей логике, после чего отсылает подтверждение платформе ESXi о том, что миграцию можно начинать. Виртуальная машина затем перемещается с помощью vMotion, после чего приложение получает оповещение о завершении миграции, чтобы оно могло также выполнить необходимые шаги, учитывая действия, совершенные на этапе подготовки.
Механизм vMotion Notifications не включен по умолчанию. Чтобы это работало, надо в расширенных настройках виртуальной машины установить параметр vmOpNotificationToAppEnabled:
После этого нужно установить host-level timeout, который будет определять максимальное время, которое есть у виртуальной машины для завершения подготовки к миграции. Для этого нужно через vSphere API установить параметр vmOpNotificationToApp.Timeout со значением большим 0. Значение устанавливается в секундах (то есть, чтобы дать приложению 5 минут, нужно установить значение 300).
Для установки данного параметра используйте ConfigManager API (см. документацию).
Приложение должно использовать утилиту командной строки vmtoolsd пакета VMware Tools для регистрации оповещений. Вот какие команды ему доступны:
На конференции Explore 2022 компания VMware объявила о выпуске новой версии платформы VMware vSphere 8, о возможностях которой мы уже писали. Сегодня мы посмотрим, что нового появилось в механизме работы томов vVols, которые позволяют более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.
Сегодня мы поговорим о нововведениях, которые появились в технологии vVols для восьмой версии платформы.
1. Поддержка технологии NVMe-oF
Это большое нововведение означает поддержку томами vVols на платформе vSphere 8 технологии NVMe-oF. В новой спецификации vVols появились определения vSphere API для механики работы с хранилищами VASA (vSphere Storage APIs for Storage Awareness) 4.0.
Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
NVMe-oF имеет преимущество в виде меньших задержек (latency) над традиционным интерфейсом SCSI. Эта технология изначально предназначена для флэш-памяти и позволяет подключать all-flash NVMe дисковые массивы с очень высокой производительностью.
В рамках технологии NVMe-oF vVols каждый объект vVol становится пространством имен NVMe Namespace. Эти пространства имен группируются в ANA group (Asymmetrical Namespace Access). Многие команды проходят как In-Band для более эффективной коммуникации между хостами ESXi и дисковыми массивами.
Также упростилась настройка томов, в том числе NVMe с технологией vVols. При развертывании NVMe в vCenter, когда зарегистрирован VASA-провайдер, оставшаяся установка происходит в фоновом режиме, а обнаружение NVMe-контроллеров происходит автоматически. Как только создается датастор, объекты vPE (virtual Protocol Endpoints) и само соединение подхватываются и обрабатываются автоматически.
2. Дополнительные улучшения vVols NVMe-oF
Они включают в себя следующее:
Поддержка до 256 пространств имен и 2000 путей
Расширенная поддержка механизма резерваций для устройств NVMe - это позволит поддерживать функцию Clustered VMDK для кластеризованных приложений, таких как Microsoft WSFC на базе хранилищ NVMe-oF
Функции автообнаружения в механизме NVMe Discovery Services для ESXi при использовании NVMe-TCP для обнаружения контроллеров NVMe
3. Прочие улучшения
Улучшение VM swap - уменьшенное время при включении и выключении для обеспечения лучшего быстродействия vMotion
Улучшенная производительность компонента config-vVol - убраны задержки при обращения виртуальных машин к платформе ESXi
В рамках событий первого дня проходящей сейчас конференции VMware Explore 2022 была анонсировала платформа виртуализации VMware vSphere 8. Это событие очень ждали многие администраторы и менеджеры датацентров, так как с момента релиза прошлой мажорной версии платформы VMware vSphere 7 прошло уже два с половиной года. Давайте посмотрим, что нового в VMware vSphere 8...
Компания VMware обновила свой гипервизор для архитектуры ARM на сайте проекта Labs - ESXi ARM Edition 1.10. В будущем этот гипервизор найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM 1.9 мы писали в апреле этого года.
Давайте посмотрим, что нового в ESXi ARM Edition 1.10:
Теперь поддерживается апгрейд с прошлых версий ESXi-Arm 1.x
Поддержка Arm DEN0115 (доступ к конфигурации PCIe через интерфейс firmware, протестировано на Raspberry Pi)
Поддержка L3 cache info для Ampere eMAG
Небольшие улучшения для non-cache coherent DMA
Статистики для Raspberry Pi NIC (genet)
GOS: возможность использования VNXNET3 и PVSCSI как драйверов по умолчанию в freebsd12
Поддержка чипов RK3566 SBC (например, Quartz64) - как PCIe, так и EQOS onboard NIC
Исправлены ошибки для драйвера Intel igbn NIC (повышена стабильность работы)
Возвращается нулевой код ошибки для unknown sys_reg(3, 0, 0, x, y) для виртуальных машин
Данные телеметрии - собирается статистика о системе, на которой запущен гипервизор
Вот какие данные собираются в рамках телеметрии в целях улучшения продукта:
CPU info: число ядер, NUMA, производитель и т.п.
Firmware info: вендор и версия
Platform info: вендор, продукт, UUID, список устройств
ESXi-Arm info: версия, уровень патчей, билд продукта
Скрипт /bin/telemetry выполняется при каждой загрузке и в 00:00 каждую субботу
Скачать VMware ESXi ARM Edition 1.10 можно по этой ссылке.
Компания VMware на днях выпустила два обновления своей платформы виртуализации vSphere 7 - ESXi 7 Update 3f и vCenter 7 Update 3f. Напомним, что об обновлении vSphere 7 Update 3d мы писали вот тут.
Давайте посмотрим, что в них появилось нового.
VMware ESXi 7 Update 3f:
Данный релиз исправляет уязвимости, описанные в бюллетенях CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 и CVE-2022-29901. Для подробной информации об этих проблемах вы можете обратиться к статье VMSA-2022-0020.
Добавлена поддержка vSphere Quick Boot для следующих серверов:
Исправления уязвимостей CVE-2022-22982 (подробнее тут) и CVE-2021-22048 (подробнее тут)
Улучшения масштабируемости архитектуры VMware HCI Mesh - теперь один кластер vSAN может обслуживать локальные датасторы до 10 клиентских кластеров vSAN
Улучшения компонентов vSphere Client - исправлены некоторые проблемы с дата-гридами, инвентарем (более компактное представление), Related Objects и Global Inventory Lists. Ну и в целом улучшено юзабилити клиента.
Обновление инфраструктуры VMware vSphere with Tanzu (подробнее тут)
Как вы знаете, через интерфейс esxcli на сервере VMware ESXi можно устанавливать расширенные настройки (Advanced Settings). Список таких доступных настроек можно вывести командой:
esxcli system settings advanced list
При этом не все пространства имен (namespaces) доступны через этот интерфейс командной строки. Эти настройки, в таком случае, как правило, доступны через интерфейс vSphere Client, но вам может понадобиться заскриптовать их. Об этом рассказал Дункан Эппинг.
Некоторые администраторы vSphere знают, что есть также такой интерфейс vim-cmd, который уже не рекомендуется использовать, но, тем не менее, его еще можно применять для установки некоторых настроек. Среди них, например, есть настройка Config.HostAgent.ssl.keyStore.allowSelfSigned для разрешения самоподписанных сертификатов на хостах ESXi.
В этом случае вы можете использовать команды в следующем формате:
vim-cmd hostsvc/advopt/update name.option type value
Для самоподписанных сертификатов нужная команда выглядит так:
Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.
Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:
Итак, лимиты можно разделить на 2 категории:
Глобальные лимиты для инфраструктуры (виртуальный датацентр).
Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).
Если говорить о глобальных параметрах, то значения тут следующие:
Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
Всего можно запустить до 2000 одновременных операций на один сервер vCenter.
На уровне хостов ESXi есть следующие механизмы работы и ограничения:
Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:
Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).
Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).
Для датасторов также есть слоты и ограничения на одновременные операции:
У одного датастора есть 128 слотов.
Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.
Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):
У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.
Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.
На сайте проекта VMware Labs вышло обновление USB Network Native Driver for ESXi 1.10. Напомним, что это средство представляет собой нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этих драйверов мы писали вот тут.
Давайте посмотрим, что нового в версии пакета 1.10:
Добавлена поддержка VMware ESXi 7.0 Update 3c и 3d
Исправлена проблема с выпадением ESXi в BSOD при использовании драйвера с последними версиями ESXi
Драйверы версии 1.10 подходят только для ESXi 7.0 Update 3c и Update 3d, вот их дистрибутив:
Таблица поддерживаемых устройств теперь выглядит так:
Для других версий ESXi нужно использовать одну из предыдущих версий драйвера. Вот, например, обновилась также и версия 1.9, куда были добавлены следующие возможности:
Добавлена поддержка ESXi 7.0 Update 3, 3a и 3b.
Добавлена поддержка идентификаторов VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100.
Исправлена проблема в механизме управления питанием в xHCI.
Сканирование шины USB (usbBusFullScanOnBootEnabled=0) отключено по умолчанию, что позволяет предотвратить выпадение в PSOD для пользователей, у которых есть несколько сетевых карточек USB.
Этот релиз предназначен только для ESXi 7.0 Update 3, Update 3a и Update 3b:
В ESXi 7 Update 3d появилась поддержка технологии vSphere Quick Boot для следующих платформ:
Dell Inc. C6420 vSAN Ready Node
Dell Inc. MX740C vSAN Ready Node
Dell Inc. MX750C vSAN Ready Node
Dell Inc. PowerEdge R750xa
Dell Inc. PowerEdge R750xs
Dell Inc. PowerEdge T550
Dell Inc. R650 vSAN Ready Node
Dell Inc. R6515 vSAN Ready Node
Dell Inc. R740 vSAN Ready Node
Dell Inc. R750 vSAN Ready Node
Dell Inc. R7515 vSAN Ready Node
Dell Inc. R840 vSAN Ready Node
Dell Inc. VxRail E660
Dell Inc. VxRail E660F
Dell Inc. VxRail E660N
Dell Inc. VxRail E665
Dell Inc. VxRail E665F
Dell Inc. VxRail E665N
Dell Inc. VxRail G560
Dell Inc. VxRail G560F
Dell Inc. VxRail P580N
Dell Inc. VxRail P670F
Dell Inc. VxRail P670N
Dell Inc. VxRail P675F
Dell Inc. VxRail P675N
Dell Inc. VxRail S670
Dell Inc. VxRail V670F
В VMware vCenter 7.0 Update 3d появились следующие улучшения:
Исправление проблемы безопасности CVE-2022-22948. Более подробно об этом рассказано тут.
Множество исправлений ошибок, полный список которых приведен тут. Решены проблемы с развертыванием ВМ из OVF-шаблонов, исправлены ошибки с накатыванием инкрементальных патчей vCenter, а также проблема с сообщением о невозможности подключения к серверу Single Sign-On.
Обновлены компоненты VMware vSphere with Tanzu, подробнее об этом рассказано тут.
Обновлены компоненты Photon OS, подробнее об этом рассказано тут.
Скачать компоненты VMware vSphere 7.0 Update 3d можно по этой ссылке. Release Notes доступны тут:
На сайте проекта Labs стала доступна новая версия гипервизора VMware под аппаратную архитектуру ARM - VMware ESXi Arm Edition 1.9. В будущем этот гипервизор найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали в декабре прошлого года.
Экспериментальная поддержка платформ Marvell Octeon TX2 CN92xx/CN93xx/CN95xx/CN96xx/CN98xx
Улучшенная поддержка оборудования PL011 UART
Поддержка VMM для ID_AA64ISAR2_EL, а также исправления ошибок для новых ядер Linux (>= 5.17-rc2)
Поддержка PCIe Enhanced Allocation
Улучшения логирования для шины PCIe
Улучшения в механизме виртуализации MSI
Исправления ошибок
Скачать VMware ESXi ARM Edition 1.9 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново (но доступна опция "Preserve VMFS" для сохранения ВМ на томах).
Многие компании сталкиваются сегодня с необходимостью переезжать на другую платформу виртуализации из-за сложностей, связанных с поддержкой зарубежных решений, а также ростом курсов валют. Сегодня мы расскажем об одной из альтернатив, которую предлагает российскому бизнесу компания HOSTVM, и рассмотрим алгоритм миграции на платформу. Сама по себе платформа HOSTVM представляет собой российскую версию гипервизора, построенного на базе открытого исходного кода KVM...
На сайте проекта VMware Labs обновился продукт Community Networking Driver for ESXi до версии 1.2.7. Напомним, что этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. О прошлой версии этих драйверов мы писали осенью прошлого года вот тут.
Давайте посмотрим, что нового появилось в версии 1.2.7 сетевых драйверов:
Поддержка устройств Intel I225 с любым идентификатором PHY ID
Поддержка новых устройств Intel I226-K (также для любых PHY ID)
Исправлен возможный дэдлок в изменяющемся MTU
Исправлено возможное зависание RX при операциях device layer ops
Исправлена возможная ошибка PHY reset failure
Драйверы работают для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:
Установка драйверов производится следующей командой (после этого нужно перезагрузить хост):
esxcli software vib install -d /path/to/the offline bundle zip
Скачать пакет драйверов VMware Community Networking Driver for ESXi 1.2.7 можно по этой ссылке.
Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:
Hardware for Use with VMware vSphere
ESXi and Virtual Machines
Guest Operating Systems
Virtual Infrastructure Management
Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.
Документ очень полезный, состоит из почти ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.
Скачать Performance Best Practices for VMware vSphere 7.0, Update 3 можно по этой ссылке.
Недавно мы писали о выходе новой версии пакета продуктов VMware Cloud Foundation 4.4, предназначенного для создания виртуального датацентра организации. Напомним, что он включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
Напомним, что одной из новых возможностей VCF 4.4 стало то, что теперь сервис SSH отключен на всех хостах ESXi по умолчанию - это новая конфигурация, которая применяется в соответствии с рекомендациями по безопасности.
Если по какой-то причине на одном или нескольких хостах в рамках доменов рабочей нагрузки (workload domains) вам нужно использовать SSH, то вот как можно это сделать.
Чтобы включить SSH на всех доменах и хостах ESXi вашей инфраструктуры, нужно выполнить следующую консольную команду SDDC Manager как root:
/opt/vmware/sddc-support/sos --enable-ssh-esxi --domain-name ALL
Если нужно включить SSH на одном из доменов, то делается это так:
Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.
Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:
Для работы с Trusted Certificate Store
можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:
#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates
Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }
Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:
#Read the certificate or certificate chain from a .pem file
$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw
#Add it to the trusted certificate stores of the vCenter and the ESXi servers
Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain
Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:
2. Управление SSL-сертификатами компьютеров на сервере vCenter Server
Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).
Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:
Get-VIMachineCertificate -VCenterOnly
После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:
После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:
Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.
3. Управление SSL-сертификатами машин для серверов ESXi
Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.
После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.
Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.
$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `
-Location (Get-Datacenter "My Datacenter")`
-User "My User" `
-Password "My Password"
RSS
